Freaks Macintosh Archive/Freaks Macintosh Archive.bin/Freaks Macintosh Archives/Hacking & Misc/Mac Satellite.sit/Mac Satellite/Season9 Info/Videocrypt Information

Text File | 1995-08-28 | 26KB | 480 lines

Some technical details about Videocrypt that Markus Kuhn wrote on the 18th
June 1994

In this file, I'll collect some of the details known or assumed about the
Videocrypt pay-TV access control system. Consider it as some kind of
frequently asked questions list with answers about the system.

1 Basic principle

Videocrypt encodes the TV image by cutting each line of the image in two
pieces at some cut point and then exchanges these two line fragments in the
broadcasted pictures. E.g. if a line like

0123456789

passes the encoder, the output might look like

4567890123

where the digits represent the pixels of the image. There are 256 possible
cut points and there are no cut points directly near the image border (the
miniumum distance from the margin is about 12-15% of the image width) which
is the reason why you sometimes still can see vertical patterns even on an
encrypted image. The sound is currently not encrypted.

Several times per second, a computer at the broadcasting station generates a
32 byte long message which is broadcasted encoded together with forward
error correction information in the first invisible lines of the TV signal
similar to teletext. About every 2.5 seconds, one of these 32-byte messages
is processed in the encoder by a secret hash algorithm which transforms the
32-byte message into a 60-bit value. These 60 bits are then used by a second
algorithm in order to determine the 8-bit cut point coordinates for each
line for the next 2.5 seconds. No details about this second algorithm are
known, but think of it just as some kind of 60-bit pseudo random number
generator (PRNG) were the 60-bit output from the secret hash function is
used as a start value (seed).

The decoder receives the 32-byte messages and other data together with the
TV signal, applies some error correction algorithms and passes all 32-byte
packets to the smart card in the decoder's card slot. The smart card
implements the same secret hash function and answers with the same 60-bit
value as the one which is used in the encoder. By using this 60-bit answer
from the card, the decoder hardware can generate with the same PRNG the same
cut point sequence as the encoder and can so reconstruct the original image
by again exchanging the two line fragments. The secret hash function is a
cryptographically strong system which is designed so that it is extremely
difficult to guess the algorithm of this function by looking at many pairs
of 32-byte/60-bit values.

Apart from being the source for the generation of the 60-bit PRNG seed, the
32-byte messages from the broadcasting station contain card numbers so that
individual cards can be addressed and they contain commands like activation,
deactivation, or show-a-message for the addressed card. In addition, the
32-byte packets contain a digital signature (currently 4 bytes) that allows
the card to test whether the 32-byte messages really originate from the
encoder and have not been generated by someone analysing the card. Again,
this digital signature like the hash function has been designed so that it
is difficult to find out how to generate a correct signature by looking at
enough examples. This prevents choosen-text attacks, where someone tries to
probe the secret hash function with very carefully selected 32-byte messages
and this prevents hackers to generate new activation commands for the card.

In early 1993, someone managed to get access to the secret hash functions of
several stations which use Videocrypt (e.g., British Sky Broadcasting, Adult
Channel, JSTV, BOB, Red Hot TV). All these systems used the same hash and
signature algorithm and the only difference between the stations was a
32-byte secret key table. It is not known,how it was possible to get this
information. Either someone from the company who manufactured the cards
(News Datacom) leased this information or it was possible for someone to
read out the EPROM contents of the card rocessor (less likely, but also
theoretically possible). With this knowledge it was then uite easily
possible for the original hackers to produce 'clone cards'. These are simple
PCBs with a cheap microcontroler (e.g. one of Microchip's PIC family), which
implements only the secret hash function and serial I/O procedures in units
EPROM and answers with the correct 60-bit values to 32-byte messages just as
the real cards do. For several channels, clone cards are still available,
but BSkyB distributed new 09 series cards in spring 1994 and switched on
1994-05-18 to a new secret hash function. Consequently, all clone cards
stopped to work. It is not known whetheronly the secret 32-byte key was
changed, or whether also the hash and/or signature algorithm have been
modified. Even if the algorithm is still the same, it is extremely difficult
to find out the new 32-byte key table.

The clone cards didn't implement any interpretation procedures for card
activation or deactivation and pay-per-view functions, so their software is
considerably simpler than the one in the real cards. This resulted in some
tiny differences between the reaction of the clone card software and the
reaction of the original card software on pathological 32-byte messages.
These differences were used in counter measures against clone cards several
times in 1993 and 1994 by BSkyS in order to deactivate clone cards, but it
was quite easy each time to find out these tiny bugs in the clone card
software and correct it.

There is an Intel 8052 microcontroler in the decoder which manages the
communication between the smart card and the rest of the system. As the
software of this processor is not read protected, it was also possible to
reprogram this chip (by using the EPROM version 8752BH) so that the hash
algorithm is performed inside the decoder. Then no external card is needed
at all for the channels for which the hash algorithm was implemented in the
8752.

More detailed basic information about Videocrypt has been published in the
European patent EP 0 428 252 A2 ("A system for controlling access to
broadcast transmissions"). You can order a copy for little money from the
European Patent Office if you are interested.

2 Security of the Videocrypt system

The system is very secure, because all secret parts that are essential to a
successful decryption are located in the smart card and if the card's secret
hash algorithm/key becomes known, it can easily be replaced by just sending
new cards to the subscribers. This card exchange can also be used if details
about the format of the commands hidden in the 32-byte sequences sent to the
card become known.

There are however at least two obvious security flaws of the system which
can't be removed by new smart card generations:

  - The dialog between the card and the decoder is the same synchronously
    for all Videocrypt decoders switched to this channel. I.e., the decoder
    doesn't add any card specific or decoder specific information to the
    traffic. This makes it possible to use one card for several decoders.
    E.g. it is possible to record the 32-byte messages broadcasted by
    the station during an evening with a PC, then send these messages to
    someone else with an original card who asks his card for the 60-bit
    answers to all the recorded messages. If this person then sends
    these 60-bit answers back, then you can use this data in order
    to descramble the VCR recorded program of this evening (delayed data
    transfer). However, decoding VHS recorded encrypted signals produces
    minor color distortions and a few VCRs don't preserve the Videocrypt
    data stream in the first invisible lines that accompanies the TV
    signal. It is also possible to distribute the 60-bit answers from
    one card in real-time with cables to many decoders in a house or
    with radio signals to many decoders in a larger region.

  - The simple cut-and-exchange encryption method and the fact that two
    consecutive lines in an image are almost always nearly identical
    makes it possible to try all 256 possible cut points and to select
    the one which causes both lines to fit together best. This method
    has alreday been implemented on fast PC's with framegrabbers which
    load the image into the memory and display it corrected on the computer
    screen (many seconds per frame), on parallel supercomputers which
    allow almost real-time decryption and with special hardware that
    achieves real-time decryption. Howevery, with this decoding method,
    there are severe image quality losses and many additional problems
    which together with the high hardware costs required (much higher
    than a regular subscription) don't make this approach very practical
    for every day usage.

Both these security gaps in the videocrypt systems don't allow comfortable
and easy high quality decryption like using a card, but the described
methods have already been successfully used by a few technically skilled
peoples for watching encrypted program.

3 ISO card protocol

The card and the protocol used to cummunicate with it conform exactly to the
international standard ISO 7816. The options used from this standard are:
T=0 asynchronous halfduplex character transmission protocol, active low
reset and inverse convention. Only a few basic principles of the ISO
protocol will be explained here. For much more detailed information, please
read the ISO standard which you can order from your national standards body
(e.g. DIN, ANSI, AFNOR, BSI, DS, etc.). There are three parts of the
standard: ISO 7816-1 describes physical characteristics of the card and
quality tests a card has to survive, ISO 7816-2 describes the location and
meaning of the contacts and ISO 7816-3 (most important) describes the
electrical characteristics, the answer-to-reset message and the protocol.

The data format is an asynchronous 9600 bit/s serial format similar to that
used on RS-232 lines with 8 data bits, 1 parity bit and two stop bits. The
parity is even (but if inverse bit meaning convention is used, a RS-232
interface has to be programmed for odd parity in order to produce the
correct bit). There is also an error detection and character repetition
mechanism in the protocol which is not supported by RS-232 interfaces: If
the receiving device (card or decoder) detects a parity error, it sends an
impulse during the stop bit time. This will tell the sender to retransmit
one byte.

After a reset impulse to the card, the card answers with an answer-to-reset
message with some information about the requirements of the card. If the
first byte is 3fh, then this means that in order to read the bytes with a
RS-232 interface, you'll have to invert and reverse all bits. A typical
answer-to-reset looks e.g. like the following one:

     3f fa 11 25 05 00 01 b0 02 00 00 4d 59 00 81 80
         |  |  |  |  | | 'historic characters' with|
         |  |  |  |  | | information about chip and|
         |  |  |  |  | | software version, etc.    |
         |  |  |  |  |
         |  |  |  |  +- low nibble: protocol type T=0,
         |  |  |  |     high nibble: end of ISO part
         |  |  |  |
         |  |  |  +- requests 5 additional stop bits
         |  |  |
         |  |  +- encodes programming voltage and max. programming
         |  |     current (here: 5V, 50mA)
         |  |
         |  +- clock freq.: 11h=3.5 MHz, 31h=7 MHz
         |
         +- the 0ah low nibble means: 10 'historic characters' which
            are not defined in the ISO standard are appended to
            the reset answer

The answer-to-reset message has a variable length format. Some bits specify
whether certain bytes are present or not. If the lowest bit in the high
nibble of the second byte is 1, then the above shown third byte is present
and determines the relation between the bit rate and the clock frequency
after the reset answer. E.g., 11h means that 372 clock cycles are one bit
duration (default), i.e. with a clock frequency of 3.5712 Mhz, the bit
frequency is 9600 Hz. In the Videocrypt system, the bit rate is always 9600
bits/s, but a value of 31h (= factor 744) in the third byte requests a
doubled clock frequency (~7MHz) from the decoder. Other values are not
supported by the Videocrypt decoder.

The Videocrypt decoder supports several programming voltages (5 V, 12.5 V,
15 V and 21 V, max. 50 mA current) and different numbers of stop bits (>= 5)
sent to the card. All these parameters can be selected in the
answer-to-reset. Of the 'historic characters' part, the decoder only
verifies that it is at least 7 characters long and that the values 4dh und
59h are at the positions as in the example, otherwise the card is rejected.
No more details about the information in the historic characters part of a
Videocrypt card is currently known. For the detailed format of the
answer-to-reset message, please consult ISO 7816-3.

The T=0 protocol is a half duplex master slave protocol. The decoder can
send commands to the card followed by a data transmission either to or from
the card. The card can do some limited flow control and can request or
deactivate the programming voltage VPP selected in the answer-to-reset using
"procedure bytes". If the decoder initiates a command, it sends five header
bytes to the card, e.g.

     53 78 00 00 08

The first byte (CLA) is the command class code and is always 53h in the
Videocrypt system. The second byte (INS) is the instruction code. Its lowest
bit is always 0 and instruction codes have never a 6 or 9 high nibble
(you'll see below, why). The following 2 bytes (P1 and P2) are a reference
(e.g. an address) completing the instruction code and a Videocrypt decoder
sets them always to 00 00. The final byte (P3) codes the number of data
bytes which are to be transmitted during the command. P3=0 has a special
meaning: In data transfers from the card, it indicates 256 data bytes, in
data transfers from the decoder, it indicates 0 bytes. The direction of the
data transfer is determined by CLA and INS and must be known in advance by
both the card and the decoder.

After transmission of such a 5-byte header, the decoder waits for a
'procedure byte' from the card.

The following procedure bytes are possible:

  60h             Please wait, I'll send another procedure byte soon,
                  don't timeout.

  INS             Now let's transfer all (remaining) data bytes, I don't
                  need programming voltage.

  INS+1           Now let's transfer all (remaining) data bytes and please
                  activate VPP.

  INS xor ffh     Now let's transfer another single data byte,
                  I don't need programming voltage.

  (INS+1) xor ffh Now let's transfer another single data byte, and please
                  activate VPP.

  6Xh or 9Xh      This byte SW1 indicates an end of the data transfer
                  and requests to deactivate VPP. A second status byte SW2
                  follows from the card. SW1 SW2 = 90 00 indicates a
                  normal termination, other values report e.g. an error.

After each data transfer, the decoder waits for another procedure byte.
E.g., a typical decoder<->card dialog looks like this (command 78h requests
the 60-bit answer as 8 bytes from the card):

     decoder sends header
       53 78 00 00 08
     card sends procedure byte (all at once, no VPP)
       78
     card sends P3 data bytes
       80 52 02 79 f5 39 7c 0e
     card closes with SW1 and SW2
       90 00

4 Videocrypt protocol

The newer Videocrypt smart cards don't require any programming voltage.
Although, the ISO standard requires only 2 stop bits after each transferred
byte, Videocrypt decoders seem to require more than 5 stop bits. As PC
serial ports don't support more than 2 stop bits directly, a card emulator
software has to wait for about 0.5-1.5 ms after each byte. Cards can
announce in the answer-to-reset message, how many stop bits they require.

A videocrypt decoder knows the following 10 commands (all with CLA=53h and
P1=P2=00h):

     INS     length (P3)      direction        purpose
    ---------------------------------------------------------------------
     70h         6            from card        serial number, etc.
     72h        16            to card          message from previous card
     74h        32            to card          message from station
     76h         1            to card          authorize button pressed
     78h         8            from card        60-bit answer
     7ah        25            from card        onscreen message
     7ch        16            from card        message to next card
     7eh        64            from card        ???
     80h         1            to card          ???
     82h        64            from card        ???

The following things are known about the data bytes of these commands:

70h:

In BSkyB cards, the 70h data contains the card issue number (e.g. 07 or 09)
in the low nibble of the first byte. The high nibble of the first byte seems
to be always 2. The next 4 bytes form an 32-bit bigendian integer value
which corresponds to the decimal card number without the final digit of the
card number (which is perhaps a check digit, algorithm unknown). The meaning
of the final byte is unknown.

72h and 7ch:

Several times per second, the decoder requests with 7ch 16 bytes from the
card. If a card is removed and a new card is inserted in the decoder without
switching off the power of the decoder, then shortly after the card reset,
the decoder sends the latest 7ch data bytes from the previous card in a 72h
message to the new card. In this way, 16 bytes information (e.g. the status
of a pay-per-view account or a list of activated channels?) can be
transfered from one card to the next.

74h and 78h:

The 74h command transfers the 32-byte messages from the broadcasting station
to the card. If the third bit (value 8) in the first byte is set, then the
decoder will ask with a 78h command for the 60-bit answer. This happens
about every 5th 74h packet every 2.5 seconds. The high nibble of the final
byte in the 78h data is ignored by the decoder (only 60 bits are needed).
The high nibble of the first 74h byte seems to have the value eh or fh in
normal encrypted operation and ch or dh in the 'soft scrambled' mode where
the decoder can descramble the image even without any card.

The following information is valid for the 07 BSkyB card and need not
necessarily be true for future smart cards, because these data bytes don't
seem to be interpreted in the decoder and so their meaning can be exchanged.
A typical BSkyB 74h packet for the 09 series card looks like this:

  e843 0a888261 0c 29e403f6 20202020202020202020202020202020 fb54ac02 51

The second byte selects one of several 32-byte secret key tables that are
used by the hash function. When the switchover from the 07 cards to the 09
cards happened, this value increased from 40h to 43h. In the 07 card, this
value was only interpreted to find an offset into a table with various
32-byte secret keys. The lower 7 bits of the seventh byte contain a channel
ID. The final byte 32 is a simple checksum that makes the sum of all 32
bytes a multiple of 256. The 4 bytes 28-31 contain the digital signature
that is simply an intermediate result of the iterations of the hash
algorithm. If the checksum, the digital signature, or some of the values in
the first 7 bytes of a 74h command aren't correct, then the 78h answer will
only contain 8 00 bytes or in some cases 01 00 00 00 00 00 00 00. The 07
card had an interesting security hole: The card sends to the decoder as many
data bytes as specified in P3. By sending a higher length value in the
command header to the card, one can get up to 256 data bytes back which seem
to be values from the card's RAM that allow some insight into the internal
data structures of the card software.

The following theory has been proposed about the encoding of the card
addresses, but this hasn't been verified yet and might be partially or
completely wrong: A card number is perhaps represented by a 5 byte card
address consisting of a 4 byte prefix and a 1 byte suffix. Up to 16 cards
with the same card address prefix can be addressed with one 32-byte message.
The bytes 8-11 might contain the common prefix to the addressed cards and
the bytes 12-27 the various suffixes. If there are less than 16 different
cards to be addressed, then the same suffix byte is repeated several times
in order to fill the space. There's no good theory about the meaning of the
4 bytes 3-6. E.g. the command which is sent to the card could be encoded
there, but no details are known and as these bytes seem to have pretty
random values, it is possible that some of these are random bytes or time
stamps and that the other bytes are encrypted with e.g. intermediate values
of the hash function (like the signature).

76h:

If the authorize button on the decoder is pressed for a few seconds, then
the decoder will send a single 76h message with a 00 data byte to the card.

7ah:

This command requests from the card an ASCII text which is then displayed on
the TV screen. The display field is 12 characters wide, one or two lines
high and no lowercase letters are supported. The lower 5 bits in the first
byte indicate, how long the text is which is to be displayed: 0 for no
display, 12 for a single line and 24 for 2 lines. The highest 3 bits of the
first byte seem to be some kind of display priority. The number there (0-3)
must be high enough if standard decoder messages have to be suppressed. The
remaining 24 bytes contain the ASCII test.

The meaning of the other commands is unknown, some of them are never used
currently. Some cards understand also additional instruction codes which
can't be issued by a normal decoder. E.g. a BSkyB 09 card understands also
12h, 86h, 88h, 8ah and 8ch. These commands are perhaps used in order to test
or configurate the card at the factory, etc.

Please contact me if you find out anything new. My e-mail address is
[e-mail]

5 VCL File Format

The Videocrypt Card Logfile format (VCL) is used by some peoples for
performing the delayed data transfer procedure described in section 2.
Person A with a valid card can record the dialog between the decoder and the
card for a certain program P and transmit this information as a VCL file to
person B who has no card and has recorded with a VCR only the encrypted
signal of program P. Person B now connects the Videocrypt decoder between
the VCR and the TV set and connects the card slot of the decoder to a PC.
Using the information in the VCL file, B's computer can now also decrypt
program P. This is of course only possible for the few hours which are
covered by the information in the VCL file.

Not all of the information exchanged between the card and the decoder is
necessary for descrambling the TV signal. The VCL format uses this fact in
order to save a lot of storage space. Only 12 bytes of high entropy (that
means: almost uncompressable) are stored every 2.5 seconds. So a VCL file of
a 1 hour program is only about 17 kbytes large. In addition, VCL files don't
contain any information about the card owner (especially not the card serial
number), which appears in normal full log files. (The only potential
security hole is the remaining nibble in the 78h data, consequently it
should be cleared in order to avoid card specific information to leak into
the VCL file.)

VCL files have a very simple binary format consisting of a 128 byte header
and arbitrarily many 12 byte records. At the end, VCL files may be padded
with zero bytes to a multiple of the operating system's disk sector size, so
that no RAM contents can leak in there out of an unsecure system like
MS-DOS. Don't forget to use a binary mode if you transfer VCL files or their
contents will be rendered unusable.

The 128 byte header has the following format:

      byte number       purpose

        0 -  3          ASCII String 'VCL1' which identifies the file
                        type and version of the format.
        4 -  7          The number of 12-byte records stored in this
                        file encoded as a bigendian (most significant
                        byte first) 32-bit unsigned integer value.
        8 - 23          Date and time when the recording started.
                        Format: yyyymmddThhmmssZ, where yyyymmdd are
                        year, month and day (e.g. '19940618'), hhmmss
                        are hour, minute and second (e.g. '235959'),
                        T ist just the ASCII letter T, and Z is
                        the ASCII letter Z if the time is UTC or
                        a zero byte, if the time is local time. The
                        digits are ASCII characters.
       24 - 55          Name of the satellite or cable system from
                        which the recording was done. This is a zero
                        terminated ASCII string with only characters
                        between 20h and 7eh. As many zero bytes are
                        appended as necessary for filling up the 32
                        bytes. The same format is also used for the next
                        two text fields. Example: 'Astra'.
       56 - 63          Name/number of the transponder from which
                        the recording was done. Example: '08' for
                        Sky One on Astra.
       64 -127          Description of what has been recorded.
                        Example: 'Star Trek: TNG, episode 123'

After the first 128 bytes follow as many 12 byte records as announced in
bytes 4-7. Each record represents a 74h/78h Videocrypt protocol pair and
constists of two fields: The first 4 bytes are the final 4 bytes of the 74h
data part, the remaining 8 bytes are the data part of the corresponding 78h
command. Four bytes of each 74h packet are enough to allow a card emulator
to quickly and reliably synchronize with the queries of the decoder. The
final four bytes of the 74h commands have been selected because of their
high entropy (signature and checksum).

----------------------------------------------------------------------------
Return to the Home Page of tron
----------------------------------------------------------------------------

[last modification 1995-07-04]